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PREFACE 


This  report  Is  the  first  of  a  series  that  will  describe  experiments 
conducted  on  the  ARPA  Experimental  Network  by  the  ARPA  Information  Pro¬ 
cessing  Techniques  (IPT)  Project  at  Rand.  Sponsored  by  ARPA,  the  project 
is  an  Integral  part  of  both  the  client's  and  Rand's  overall  program  to 
explore  the  utilization  of  computer  resources  applicable  to  military 
environments . 

The  problem  addressed  by  the  ARPA  Network,  and  by  Rand  as  a  partic¬ 
ipating  node,  is  how  fo  economically  share  heterogeneous  computer  re¬ 
sources  that  are  separated  geographically.  Network  development  is  divided 
into  two  phases:  (1)  research  and  experimentation,  and  (2)  provision  of 
services  to  an  extended  ARPA  research  community.  We  are  approaching  the 
second  phase,  that  is,  3ome  services  are  being  offered  on  a  limited  basis, 
but  experimentation  and  development  will  continue. 

As  introductory  material,  this  report  gives  an  overview  of  the  ini¬ 
tial  work  completed  at  Rand.  Its  readers  include  Rand  researchers  who 
will  use  the  Network  to  access  remote  resources,  and  users  at  remote  sites 
who  will  use  Rand-provided  resources .  Background  and  overview  of  the 
Network  are  given  for  potential  users  vho  are  not  familiar  with  J ts  oper¬ 
ation  and  scope.  A  description  of  the  Rand  Video  Graphics  System  is  in¬ 
cluded  for  those  unfamiliar  with  our  configuration. 

Because  no  services  are  yet  offered  by  Rand,  this  report  is  neither 
a  tutorial  nor  a  user's  guide  tc  services.  Rather,  the  functional  organ¬ 
ization  and  operation  of  rhe  Network  is  explained  and  reference  is  made  to 
the  kinds  of  uses  (services)  to  which  Rand  experiments  will  be  directed. 
The  motivation  and  results  of  future  experiments  will  be  contained  in  sub¬ 
sequent  reports  of  this  series. 
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SUMMARY 


This  report  is  an  introduction  to  the  ARPA  Network  at  Rand.  Over¬ 
views  of  the  Network  and  of  the  Rand  Video  Graphics  System  are  presented. 

The  ARPA  Network  is  a  distributed  digital  network  with  nodes  lo¬ 
cated  on  the  premises  of  various  ARPA  contractors.  It  can  be  viewed  as 
a  research  project  to  examine  ways  of  sharing  computer  resources  among 
different  kinds  of  computers  and  operating  systems.  It  can  also  be  viewed 
as  a  facility  that  provides  services  to  a  large  group  of  users. 

The  results  of  previous  Rand  studies  on  distributed  digital  communi¬ 
cation  systems  were  useful  as  ?  foundation  for  the  design  of  the  ARPA 
Network.  The  ARPA  Network  was  designed  by  an  Interface  Message  Processor 
Group  consisting  of  representatives  from  many  of  the  ARPA  contractors 

along  with  ARPA  itself,  and  was  implemented  by  Bolt,  Beranek  and  Newman, 

t 

Inc.  1 

The  structure  and  operation  of  the  Network  are  described.  A  subnet 
is  formed  by  interconnecting  small  computers  called  Interface  Message 
Processors  (IMPs)  through  wideband  communication  lines.  The  various  host- 
computers  of  the  ARPA  contractors  are  then  connected  to  the  -MPs  to  fora 
the  Network.  Hosts  converse  via  the  IMPs.  The  IMPs  switch  standard-size 
message  packets  by  a  store-and-fo  v jrd  technique.  There  are  provisions 
for  multiplexing  messages,  acknowledging  receipt  of  messages,  and  finding 
the  beginning  and  end  of  a  message. 

Protocol  between  the  host-computers  is  managed  by  Network  Control 
Programs  (NCPs)  that  maintain  logical  message  paths  and  control  the  rate 
of  information  flow  between  processors.  The  NCP  operations  were  specified 
by  representatives  of  the  participating  sites.  NCP3  are  now  being  imple¬ 
mented  at  each  site. 

Hardware  comprising  the  Rand  Video  Graphics  System  and  its  relation 
to  the  Network  is  described.  Implementation  strategy  of  the  NCP  within 
the  framework  of  our  current  system  is  stated.  The  NCP  behaves  as  a  mini¬ 
system  controlled  by  a  task  supervisor  and  several  types  of  asynchronous 
(software)  interrupts. 

•f 

Located  at  SO  Moulton  Street,  Cambridge,  Massachusetts,  02138. 
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The  short-range  goals  for  user  programs  are  identified.  A  Network 
Service  Program,  currently  being  implemented  at  Rand,  is  offered  as  an 
approach  to  combining  experimentation  and  services  to  users  into  a  com¬ 
mon  program. 
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I.  INTRODUCTION  AND  OVERVIEW 

THE  NETWORK  CONCEPT.  PURPOSE,  AND  GOALS 

The  nationwide  ARPA  Network  [1-5]  is  composed  of  ARPA  contractors 
at  geographically  separated  sites.  Different  computers  at  these  sites 
are  Interconnected  by  small,  standardized  computers  and  50-Kbit  commu¬ 
nication  lines.  The  computers  vary  in  make,  model,  size,  speed,  and 
other  hardware  and  software  features,  as  shorn  in  Table  1.  The  Network 
is  a  distributed  network  (as  opposed  to  a  centralized  network  with  a 
central  control  node)  and  traffic  routing  is  governed  adaptively  by  the 
standardized  computers  over  redundant  network  paths.  Via  this  Network, 
each  participant  can  reliably  access  the  various  remote  resources,  such 
as  programs,  data,  and  unique  hardware  facilities.  Individual  programs 
at  the  sites  control  information  flow. 

Of  primary  concern  are  the  fundamental  intercommunication  problems 
Inherent  in  the  marriage  of  autonomous  hardware  and  software.  No  at¬ 
tempt  has  been  made  to  provide  compatible  equipment  in  order  to,  for 
example,  transfer  large  programs  as  a  means  of  resource  sharing.  On 
the  contrary,  the  necessity  for  large  program  transferability  can  often 
be  eliminated  by  transmitting  small  messages  in  a  predetermined  format 
over  standard  Interfaces,  to  be  operated  on  by  programs  written  to  run 
in  the  remote  environment.  This  approach  greatly  minimizes  reprogram¬ 
ming  efforts  and  reduces  concern  for  developing  standard  languages  and 
for  improving  hardware  compatibility.  The  Network  will  make  techno¬ 
logical  and  human  resources  more  readily  available  at  less  expense.  An 
obvious  outcome  of  the  Network  environment  is  Increased  cross  fertiliza¬ 
tion  of  research  products. 

There  are  several  other  motivations  for  this  research.  The  total 
number  of  computers  at  multiple  computer  installations  may  be  reduced. 
Such  tangible  Network  facilities  as  mass  storage  may  be  remotely  ac¬ 
cessed  and  more  efficiently  utilized.  And  the  area  of  Interprocess 
communication  can  be  more  thoroughly  explored. 

A  project  goal,  then,  is  to  discover  and  validate  techniques  and 
mechanisms  attendant  to  uniform  and  easy  access  to  all  available  re¬ 
sources,  Independent  of  hare*  are  and  software  dissimilarities.  The 
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Table  1 


NETWORK  NODES 
(October  1971) 


CONTRACTOR  AND  LOCATION 


COMPUTER(S) 


Bolt ,  Beranek  and  Newman,  Inc. 
Cambridge,  Maaaachuaetta 


Burrougha  Corporation 
Paoll,  Pennsylvania 

Carne gle-Ma lion  University 
Pittsburgh,  Pannaylvania 

Case  Western  Reserve  University 
Cleveland,  Ohio 

Harvard  University 

Cambridge,  Massachusetts 


Massachusetts  Institute  of  Technology 
Lincoln  Laboratory 
Lexington,  Massachusetts 

Massachusetts  Institute  of  Technology 
Project  MAC 

Cambridge,  Massachusetts 

Mitre  Corporation 
McLean,  Virginia 

NASA  Asks  Research  Centar 
Moffett  Field,  California 

Roae  Air  Development  Center  (ISIM) 

Rom,  New  York 

Stanford  Research  Institute 
Artificial  Intelligence  Croup 
Menlo  Park,  California 

Stanford  Research  Institute 
AugMntatlon  Research  Centar 
Menlo  Park,  California 

Stanford  University 
Computation  Centar 
Stanford,  California 

System  Development  Corporation 
Santa  Monica,  California 

The  Rand  Corporation 

Santa  Monica,  California 

University  of  California  at  Loe  Angeles 
Computer  Science  DepartMnt 
Los  Angelas,  California 

University  of  California  at  Santa  Barbara 
Santa  Barbara,  California 

University  of  Illinois 

Center  for  Advanced  Computation 
Urbana,  Illinois 

University  of  Utah 
Computer  Science/ IRL 
Salt  Lake  City,  Utah 


PDP-10 
PDP-10 
DDP-516 
Terminal  IMP 

B6S00 


PDP-10 


PDP-10 


PDP-11 

PDP-10 

PDP-1 

TX2 

IBM  360/67 


CE  645 
PDP-10 


Terminal  IMP 

IBM  360/67 
Terminal  IMP 

CE  635/645 
Terminal  IMP 

PDP-10 


PDP-10 


PDP-10 


DDP-516 
(IBM  360/67) 

IBM  1800 
(IBM  360/65) 
(PDP-10) 

Sigma  7 

IBM  360/91 


IBM  360/75 


PDP-11 


PDP-10 
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lnventory  in  Table  1  shows  the  variety  of  computer  types  in  the  present 
Network  configuration. 

More  specifically,  we  aim  to  make  remote  services  as  easily  acces¬ 
sible  as  local  ones,  without  noticeably  degrading  overall  performance. 
Although  services  could  be  shared  as  In  a  time-sharing  system,  the 
distance  between  user  and  service  could  be  vastly  extended.  Likewise, 
the  number  and  size  of  services  would  not  be  constrained,  as  in  a  typical 
time-sharing  system.  Another  goal  is  to  alJc'-’  more  flexibility  in  the 
use  of  programming  languages.  Because  services  would  be  offered  re¬ 
motely,  compatible  languages  allowing  program  transferability  would  not 
be  required. 

DISTRIBUTED  COMMUNICATIONS 

In  the  early  1960s,  Rand  began  a  study  [6-17]  of  distributed  dig¬ 
ital  communications  that  Included  system  design,  communications  routing, 
and  performance  measurement  aspects  of  distributed  digital  communications 
networks.  Such  a  network  was  designed  as  the  ARPA  Network  [18-19]  by 
many  of  the  contractors  listed  in  Table  1,  along  with  ARPA  and  others. 
American  Telephone  and  Telegraph  designed  and  Implemented  the  circuits, 
ARPA  provided  the  "plan,"  Network  Analysis  Corporation  selected  the 
topology,  Honeywell  fabricated  the  subnet  equipment,  and  Bolt,  Beranek 
and  Newman,  Inc.  (BB&N)  was  responsible  for  most  of  the  subnet  design, 
installation,  and  checkout. 

PLANNED  USES  OF  THE  NETWORK 

Such  a  network  has  many  uses.  Of  greatest  Interest,  however,  are 
those  that  readily  allow  exploration  of  communication  methods  among 
different  operating  systems.  One  such  generic  use  is  program  sharing , 
in  which  data  are  transmitted  to  a  remote  program  and  results  are  re¬ 
turned.  Another  is  data  sharing,  in  which  small  programs  or  algorithms 
are  transmitted  to  operate  on  a  large,  remotely  located  data  base.  Also 
of  general  Interest  are  remote  services,  in  which  a  remotely  located 
data  base  and  program  are  queried.  Other  possible  candidates  are  load 
sharing  and  message  services,  neither  of  which  appears  to  be  as  inter¬ 
esting  at  present. 
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Several  examples  clarify  prospective  benefits.  Program  sharing 
will  occur  when  the  ILLIAC-IV  (to  be  Included  In  the  Network)  acts  as 
a  remote  facility  for  simulation  and  modeling  functions.  This  machine 
performs  such  functions  in  a  fraction  of  the  time  required  by  conven¬ 
tional  hardware.  Parameter  data  will  be  transmitted  from  remote  sites 
as  input  to  large  simulation  programs  that  run  on  the  ILLIAC-IV.  Re¬ 
sults  of  the  simulations  will  be  returned  t:o  the  remote  sites  for  anal¬ 
ysis.  A  similar  form  of  program  sharing  is  planned  by  Rand:  researchers 
will  rim  simulation  programs  (too  large  for  Rand's  machines)  on  the  Re¬ 
mote  Job  Service  (RJS)  at  the  University  of  California  at  Los  Angeles 
(UCLA).  The  data-storlng  and  post-processing  of  the  simulation  results 
can  be  performed  via  Remote  Job  Entry  (RJE)  at  the  University  of  Cal¬ 
ifornia  at  Santa  Barbara  (UCSB) .  The  data  base  produced  by  the  RJS  can 
be  remote '.y  stored  and — in  an  example  of  data  sharing — accessed  via  RJE. 
In  this  instance,  small  post-processing  programs  are  transmitted  to 
UCSB  to  operate  on  the  simulation  results.  The  graphical  outpuL  of  the 
post-processing  programs  are  returned  to  Rand  for  local  display. 

Several  types  of  remote  service  are  already  in  use,  but  like  RJS 
and  RJE,  these  services  will  be  more  available  and  less  costly  when  in¬ 
corporated  into  the  Network.  For  example,  UCSB's  On-Line  System  pro¬ 
vides  a  remote  service  by  permitting  human  interaction  in  mathematical 
analysis;  Stanford  Research  Institute's  (SRI)  TODAS  allows  remote  con¬ 
struction  and  modification  of  arbitrary  text  files. 

USE  OF  THE  NETWORK  BY  BROADER  DISCIPLINES 

The  current  user  ropulation  consists  of  about  2000  persons,  whose 
interests  are  primarily  in  computer  sciences  technology.  Some  ARPA- 
sponsored  projects  in  this  area  that  will  make  use  of  the  Network  are 
artificial  intelligence  and  computer  system  architecture.  However, 
ARPA-sponsored  research  that  will  benefit  by  Network  use  is  variegated, 
such  as  seismology,  climate  dynamics,  and  behavioral  science. 

For  example,  the  modus  operandi  of  an  ongoing  climate  dynamics  pro¬ 
ject  at  Rand  involves  cross-town  courier  service  for  computer  runs  on 
a  machine  just  adequate  for  the  problem.  The  effects  of  this  operation 
are  long  turnaround  time  and  less  than  optimal  data  output,  because  of 


? 
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machine  size  limitations.  The  Network  can  eliminate  or  reluce  both 
problems.  It  will  be  possible  to  submit  computer  Jobs  and  obtain  re¬ 
sults  from  the  researcher's  office,  thus  eliminating  courier  service. 
Sufficient  machine  power  will  be  available  via  the  Network  to  produce 
the  desired  results  In  less  time. 

A  TRANSFER  OF  NETWORK  TECHNIQUES 

Finally,  large  corporations  would,  hypothetically,  employ  Network 
principles  to  save  the  expense  of  many  terminals  and  communication 
facilities  to  access  various  services.  These  principles  would  allow 
a  single  terminal  to  access  those  services.  Services  that  are  now 
prohibitively  expensive  for  small  companies  could  be  made  economical. 
Likewise,  the  central  processor  requirements  of  these  companies  could 
be  reduced. 

PARTICIPANTS  WITH  SPECIAL  NETWORK-ORIENTED  FUNCTIONS 

Most  of  the  current  and  Impending  Network  sites  shovn  In  Table  1 
are  expected  to  contribute  a  unique  resource  to  the  Network  community. 

In  particular,  the  operations  of  three  current  members  will  fulfill  the 
following  special  functions . 

SRI  Is  responsible  for  a  Network  Information  Center  (NIC),  which 
will  provide  access  to  documentation  of  Network  experiments  as  well  as 
Information  preliminary  to  the  use  of  remote  resources.  For  example, 
a  researcher  might  use  this  service,  via  the  Network,  to  discover  what 
programs  are  available  and  hew  to  use  them.  SRI  provides  a  partial 
library  In  hardcopy  to  each  site. 

Another  special  operation  is  the  Network  Measurement  Center  (NMC) 
at  UCLA.  Because  the  Network  Is  experimental,  it  was  programmed  to 
sample  Its  own  performance  and  send  these  statistics  to  UCLA  for  anal¬ 
ysis.  The  two  classes  of  measurements  are  message  tracing  through 
nodes  and  measuring  the  activity  of  a  single  node.  From  these  data, 
for  example,  one  can  observe  the  performance  of  the  Network  message 
routing  algorithm  under  varying  Network  loadings. 

The  third  special  function  Is  the  Network  Control  Center  (NCC) 
maintained  by  BB&N.  The  NCC  coordinates  Network  maintenance  and  testing. 
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The  Network  Is  programmed  to  send  status  information  on  itself  and  on 
the  communication  lines  to  Bfi&N,  which  monitors  Network  performance 
and  operations . 

ACCESSING  THE  NETWORK  FROM  RAND 

Rand  will  provide  access  to  the  Network  from  the  Rand  Video  Graphics 
System  (VGS)  consoles  [20].  The  VGS  consists  of  such  shared  electronic 
components  as  scan  converters.  Costs  are  amortized  over  many  concurrent 
but  different  applications.  Twenty-six  low-cost  graphics  consoles  are 
available  throughout  Rand. 

Figure  1  illustrates  the  Rand  configuration.  Users  of  VGS  consoles 
communicate  with  the  Network  by  programs  operating  in  the  IBM  360  service 
machine.  The  communication  paths  pass  through  an  1800,  which  is  used  as 
a  message  switch. 

Perhaps  the  best  way  to  describe  how  these  consoles  will  be  used  as 
a  Network  access  is  to  describe  some  current  in-house  uses  of  VGS.  Thus 
far,  the  VGS  has  been  used  mainly  to  support  research  in  man-machine 
communications.  Thus,  the  tystem's  ability  to  provide  real-time  re¬ 
sponse  of  machine  interpretation  of  human  gestures  (via  the  Rand  Tablet- 
stylus  input  device)  is  vital.  This  capability  is  used  for  such  func¬ 
tions  as  real-time  automatic  handprinted  character  recognition  and  sup¬ 
plying  highly  responsive  full-graphic  editing.  However,  the  computer 
researchers  and  the  programming  staff  of  the  Rand  Computation  Center  also 
need  remote  job  entry,  program  debugging,  and  program  editing  features. 
These  are  currently  supplied  via  IBM's  Conversational  Programming  System 
(CPS  II)  [21],  retrofitted  with  a  graphic  interface  for  VGS  (keyboard 
and  Tablet  input,  and  graphic  display  output),  and  other  support  soft¬ 
ware  programs. 

In  addition,  the  VGS  is  used  extensively  where  problem-solving  is 
enhanced  by  superimposed  computer-generated  pictures  and  noncoded  infor¬ 
mation  from  a  TV  camera. 

Figures  2-5  represent  the  various  VGS  uses.  Figure  1  shows  a  por¬ 
tion  of  a  displayed  "page"  of  programming  text  used  with  graphic  CPS  II. 
Figure  3  shows  graphs  of  simulation  results  using  a  biomedical  modeling 
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Fig.  1 — VGS  console  access  to  ARPA  network 
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Fig,  2 — Sample  of  CPS  program  text  printed  on  screen  at  74 
characters  per  line  by  52  lines  per  screen  height 


Fig. 3 — Graphs  of  simulated  results  of  biomedical  modeling  system 
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Fig. 4 — VGS  application  of  annotation  of  photograph 
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systein  [22].  Figure  A  shows  the  application  of  VGS  to  the  photo-inter¬ 
pretation  process  used  in  an  intelligence  application.  The  picture  is 
a  composite  of  an  image  from  a  TV  camera  looking  at  a  photogiaph  and 
user-described  annotation  that  is  digitally  generated  as  a  result  of 
tablet-stylus  action.  The  right  side  of  the  picture  shows  a  column  of 
computer-generated  "display  buttons"  that  allow  choice  of  line  bright¬ 
ness,  line  width,  and  solid  or  dashed  lines,  and  special  graphic  struc¬ 
tures  to  permit  on-line  annotation  of  the  picture  via  the  Rand  Tablet 
stylus  used  as  the  input  device.  For  this  application,  there  is  gen¬ 
erally  no  need  to  digitally  store  the  complex  grey  scale  picture. 
Annotation  is  user-generated,  based  on  features  Important  to  the  inter¬ 
preter.  The  annotation  is  either  generated  and  stored  on-line  and  avail¬ 
able  for  later  review,  or  a  transparent  hardcopy  overlay  can  be  generated 
by  a  film  recorded  for  use  with  the  original  photograph. 

Figure  5  shows  a  partially  constructed  flowchart  description  of  a 
biological  model.  The  flowchart  elements  are  drawn  using  a  Tablet  stylus. 

The  design  and  development  of  VGS  was  supported  by  ARPA.  The  image 
display  portion  of  the  system  was  developed  under  a  subcontract  with  IBM, 
Advanced  Systems  Development  Division,  Los  Gatos. 
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Fig,  5 — Close-up  view  of  picture  display  from  a 
block  diagram  program 
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II.  HOST- TO- IMP  AND  IMP-TO-HOST  COMMUNICATIONS 

NETWORK  CONFIGURATION 

The  different  computers  at  each  site,  called  hosts,  are  each  con¬ 
nected  to  a  small  computer,  called  an  Interface  Message  Processor  (IMP), 
on  the  host’s  premises.  The  Network  is  completed  by  interconnecting 
IMPs  through  50-Kbit  full  duplex  communications  lines  leased  from  the 
common  carriers  (Fig.  6).  The  IMPs  employ  a  heuristic  routing  and 
store-aud-forward  switching  algorithm  to  pass  messages.  A  message  is 
sent  from  a  host  to  its  IMP,  passed  from  IMP  to  IMP,  ultimately  goes 
to  the  destination  IMP,  and  then  to  the  destination  host. 

The  IMP  is  a  modified  Honeywell  DDP-516;  the  standard  interface  is 
built  by  BB&N  (Fig.  7).  Other  IMP  equipment  includes  a  teletype,  paper 
tape  reader,  and  one  to  four  modems^  for  connection  to  the  communication 
lines . 

MESSAGES 

A  host  communicates  directly  with  the  IMP  on  its  premises  by  send¬ 
ing  and  receiving  small,  fixed-length  control  messages.  Hosts  commun¬ 
icate  with  each  other  through  the  IMPs  by  transmitting  regular  messages 
of  variable  length.  Messages  consist  of  a  control  leader  and  text. 
Reference  19  gives  a  complete  description  of  leader  formats  and  their 
meanings . 

LINKS 

A  link  is  a  logical  simplex  connection*  between  two  programs  in 
remote  hosts.  The  logical  links  allow  multiplexing  outgoing  messages 
and  distributing  incoming  messages  within  the  hosts.  Programs  may  have 
multiple  concurrent  links. 

A  modem  is  a  modulator/demodulator  device  that  converts  data  be¬ 
tween  a  data  processing  form  and  a  transmission  facilities  form. 

A  simplex  connection  permits  transmission  in  one  direction  only, 
as  opposed  to  a  half-duplex  connection,  which  permits  transmission  in 
both  directions  but  not  simultaneously. 


l 
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Fig.  6— Network  Configuration 
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Fig.  7— Typical  Equipment  at  Each  Node 
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A  link  is  uniquely  identified  by  s  source  host  number  (predefined 
for  each  host  and  known  to  the  IMPs) ,  a  destination  host  number,  and 
an  identification  (multiplexing)  number. 

ACKNOWLEDGMENTS 

During  transmission  of  a  message  over  a  link,  the  link  is  unavail¬ 
able  for  otter  use.  After  the  message  has  been  delivered  by  the  destin¬ 
ation  IMP  to  its  host,  a  ready-for-next-message  acknowledgment  is  re¬ 
turned  to  the  source  host  by  the  destination  IMP  and  the  link  is  made 
available  for  further  use. 

END-0 F-MESSAGE  DETECTION 

The  end  of  a  message  is  "padded"  by  the  Interface  and  IMP  hardware 
to  permit  a  receiving  host  to  locate  the  lest  meaningful  bit  of  the 
message.  The  padding  consists  of  an  Interpretable  bit  pattern  that 
terminates  on  the  receiving  host's  word  boundary. 

HARDWARE  ANOMALIES  HANDLED  BY  THE  HOSTS 

The  hosts,  rather  than  the  IMPs,  are  responsible  for  resolving  two 
hardware  difference  problems.  First,  where  processor  word  lengths 
differ,  reformatting  is  done  by  the  receiving  host.  Second,  "merklng" 
the  beginning  of  a  message  (again  due  to  mismatched  word  lengths)  Is 
done  by  the  sending  host.  Similar  to  padding  the  messege  end,  the  send¬ 
ing  host  marks  the  start  of  the  message  beyond  the  leader  by  an  Inter- 
pretable  bit  pettern  thet  terminates  on  the  sending  host's  word  boundary. 
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III.  HOST-TO-HOST  COMMUNICATIONS 

THE  NETWORK  WORKING  GROUP  (NWG) 

An  NWG,  composed  of  represenCatlves  from  ARP A  and  from  each  Net¬ 
work  site,  coordinates  experimentation  and  development  of  the  Network 
and  provides  a  convenient  forum  for  discussing  and  formulating  Network 
protocol.  The  Initial  task  of  the  NWG  has  been  to  functionally  specify 
the  Network  Control  Program  (NCP) — the  standard  protocol  manager  between 
hosts  (discussed  below) .  This  specification  has  been  completed  and  Is 
being  implemented  by  each  site.  Current  endeavors  of  the  NWG  Include 
studying  the  requirements  for  problem  program  communications. 

NCP  DEFINITIONS  AND  FUNCTIONS 

A  standard  hoat-to-host  protocol  makes  the  study  of  program-to- 
program  conmunlcatlons  more  convenient.  It  Interfaces  the  program/ 

Network  at  the  host  level  rather  than  at  the  IMP  level  and  also  allows 
a  larger  set  of  Identifiers  for  message  paths  (than  that  provided  by 
the  IMPs)  to  be  defined.  (If  programs  are  to  operate  Independently, 
they  must  have  their  own  unique  set  of  Identifiers  for  Network  logical 
message  paths.) 

This  standard  protocol  manager  Is  the  NCP^  provided  by  each  site, 
usually,  but  not  In  all  cases,  within  Its  system  software.  The  NCP 
can  accept  and  generate  Network  messages  In  a  standard  format.  The 
messages  Include  the  link  Information  described  In  Sec.  II.  For  Network 
transmission,  the  NCPs  multiplex  outgoing  messages  over  the  links  and 
distribute  Incoming  messages  to  programs. 

The  NCP  functions,  Implemented  Independently  In  each  host  computer, 

Insure  a  common  dialogue  at  the  host-to-hoat  level  throughout  the  Net-  V 

work.  The  NCPs  support  establishing  or  terminating  connections,  mes¬ 
sage-flow  control,  Interrupts,  echoes,  ani  notification  of  detected  ) 

errors.  Typically,  NCPs  are  embedded  In  the  host's  system  software 
and  their  functions  Invoked  through  system  calls. 


Reference  5  describes  an  earlier  version  of  this  protocol.  V 


One  NCP-supported  function,  the  connection,  is  a  simplex  message 
path  between  two  remote  programs.  It  is  similar  to  the  link  of  the 
IMP-to-host  protocol,  but  provides  a  larger  range  of  identifiers.  The 
respective  programs  identify  a  connection  by  means  of  a  pair  of  iden¬ 
tifiers,  called  sockets  (one  at  each  end).  Because  a  connection  is  a 
simplex,  one  socket  is  designated  a  receive  socket  and  the  other  a  send 
socket. 

Another  NCP-supported  function,  the  message-flow  control  technique 
that  exists  between  user  programs,  differs  from  that  employed  at  the 
IMP-to-IMP,  IMP-to-host  level,  where  message  rate  is  controlled  by  ack¬ 
nowledgments.  The  same  message-transmission  acknowledgment  is  present 
at  the  host-to-host  (program- to-program)  level,  but  flow  control  over 
a  connection  must  be  further  regulated  by  the  programs  themselves.  The 
receiving  program  supplies  the  sending  progrsm  with  s  buffer-allocation 
count  for  messages  to  be  received.  When  the  allocstlon  is  exhausted, 
the  sending  progrsm' s  NCP  must  force  temporary  suspension  of  messsge 
flow  until  the  receiver  replenishes  the  allocation. 

Because  implementation  of  NCPs  and  higher-level  software  is  instal¬ 
lation  dependent,  the  next  section- limits  the  discussion  to  the  Rand 
setting. 
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IV.  THE  RAND  VGS 


OVERVIEW 

Rand's  computer  hardware  related  to  this  report  consists  of  four 
major  subsystems:  (1)  the  IBM  360/65  service  machine,  (2)  the  VGS, 
which  Includes  an  IBM  1800  with  a  picture  generator  and  a  distribution 
system,  (3)  the  consoles,  and  (4)  the  IMP. 

Note  In  Fig.  8  that  Rand's  Network  host-computer  Is  an  IBM  1800. 
Typically  used  for  process  control,  It  serves  here  as  a  communications 
control  Interface  to  other  service  machines  (currently  one  IBM  360/65) 

In  support  of  the  VGS.  The  IBM  1800  Is  responsible  for  (1)  oufferlng 
and  routing  Information  from  consoles  and  IMP  to  the  service  machine, 

(2)  buffering  and  routing  Information  from  the  service  to  the  picture 
generator  and  the  IMP,  and  (3)  providing  appropriate  hlgh-rate  feedback 
to  such  Input  devices  as  llne-at-a-tlme  buffering,  editing  for  keyboards, 
and  Rand  Tablets.  By  connecting  the  IMP  to  the  host  IBM  1800,  existing 
message  queueing  and  routing  services  were  Used  to  provide  Network  access 
as  well. 

The  VGS  Is  designed  to  serve  many  highly  interactive  users  and  to 
load  share  across  a  spectrum  of  applications  in  a  time-shared,  multi¬ 
user,  problem-solving  environment. 

DESCRIPTION 

Figure  8  Indicates  the  gross  aspects  of  the  system  now  operating 

t 

at  Rand.  The  basic  system  concept  Is  characterized  by  a  central  set  of 
shared  hardware  currently  connected  to  the  360/65  and  26  consoles  [23-25]. 

Perhaps  the  most  technically  Interesting  portion  of  the  system  Is 
the  Image  Distribution  System  (IDS)  that  lies  between  the  1800  and  the 
consoles  (Fig.  9).  The  IDS  consists  of  a  microprogrammed  graphic  dis¬ 
play  control,  a  picture  generator,  3  scan  converters,  a  32-channel  cen¬ 
tral  buffer  store,  a  distribution  panel,  a  graphic  compare,  and  a  raster 
compare.  The  more  Important  components  are  described  below. 

The  picture  generator  is  a  high-quality  line  and  character  gener¬ 
ator.  It  converts  the  graphic  order  codes  and  data  to  x,  y,  and  I 
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Fig.  9— Image  Distribution  System 
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(lntenslty  control)  analog  vectors  to  be  written  ("painted")  on  a 
selected  scan  converter. 

The  scan  converter  translates  the  x,  y ,  and  I  signals  to  an  elec¬ 
tronic  charge  pattern  on  the  target  of  a  recording  vldlcon  scan-con¬ 
version  tube.  A  picture  may  be  painted  In  any  sequence  desired.  Once 
the  charge  pattern  Is  painted  on  the  scan  converter  target,  the  picture 
generator  Is  available  for  generating  another  user's  picture  on  another 
scan  converter. 

Before  the  paint  cycle,  any  previous  Image  on  the  target  scan  con¬ 
verter  is  erased,  using  a  hlgh-lntenslty  strobe  light  to  discharge  the 
photoconductor  target.  Once  a  picture  Is  painted,  the  scan  converter 
Is  switched  to  the  raster  scan  mode  and  the  stored  Image  Is  scanned 
off  (read)  In  an  873-llne  raster  format.  The  scanned  signal  Is  stored 
on  the  selected  video  buffer  channel  (used  for  centralized  refresh  of 
the  consoles)  and  displayed  on  the  selected  console.  The  scan  converter 
Is  then  ready  for  another  paint  cycle. 

The  common  video  buffer  Is  a  J2- track,  single  read-write-head-per- 
track  disk.  Each  channel  stores  and  refreshes  one  TV  picture. 

Dynamic  portions  of  a  picture  are  updated  by  generating  a  change 
In  a  service  computer  (the  360/65).  For  some  applications,  only  the 
changed  Information  Is  routed  via  the  1800  to  update  a  track.  There¬ 
fore,  for  text  use  only,  one  buffer  channel  per  console  Is  sufficient, 
because  a  partial  rewrite  feature  may  be  used  to  replace  a  single  line 
of  text.  The  partial  rewrite  feature  allows  rewriting  any  size  hori¬ 
zontal  band  (from  one  line  to  full  screen)  of  the  picture  scan.  This 
band  may  oe  positioned  at  any  vertical  position  desired.  For  dynamic, 
full  graphic  pictures,  two  channels  per  console  may  be  used,  one  for 
static  portions  of  the  picture  and  one  for  dynamic  portions.  This 
eliminates  rewriting  the  stctic  part  each  time  the  dynamic  part  Is 
changed. 

Signals  from  several  buffer  tracks  can  br  summed  linearly  for 
transmission  to  the  appropriate  console.  Non^oded  information,  such 
as  natural  pictures  from  a  television  camera,  can  be  summed  with  coded 
pictures . 
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The  distribution  module  is  the  output  element  of  the  IDS.  Its 
functions  are 

1.  To  connect  consoles  to  the  appropriate  IDS  channel; 

2.  To  linearly  mix,  as  needed,  signals  from  the  buffer  channels 
as  well  as  externally  generated  TV  signals. 

In  certain  types  of  graphic  applications,  it  is  desirable  for 
programs  to  have  the  system  hardware  examine  a  picture  to  determine 
if  any  visible  elements  occur  in  a  certain  aiea  of  the  display.  This 
function  is  called  graphic  compare;  it  allows  a  program  to  detect  the 
presence  and  Identity  of  an  image  element  within  a  variable  program- 
defined  rectangular  "window"  within  the  display  area.  The  system  can 
perform  tnis  test  with  or  without  concurrent  track  rewrite. 

CONSOLES 

The  consoles  are  designed  to  act  as  the  user's  personal  property — 
that  is,  they  are  Inexpensive  enough  to  be  dedicated  to  a  person  with 
moderate  to  heavy  use  rates.  Consoles  are  designed  to  operate  in  the 
user's  most  productive  problem-solving  environment,  usually  his  office. 
Two  coax  cables  connect  each  console  to  the  distribution  module. 

Figure  10  diagrams  the  console.  The  console  modem  allows  the  user 
a  choice  of  up  to  eight  simultaneous  input  devices.  Thus,  the  user 
has  input  flexibility  to  match  the  output  flexibility  of  graphically 
displayed  information.  Current  input  devices  available  are  a  aelec- 
trlc  keyboard  (standard  on  all  consoles),  a  Rand  Tablet,  a  Graf  Pen 
tablet,  a  light  pen,  and  a  fan-out  device  that  will  accommodate  up  to 
32  data-entry  keyboards  per  station. 

The  keyboard  has  upper-  and  lower-case  symbols,  a  third  case  for 
special  symbols,  and  a  fourth  case  for  user-described  function  keys. 

The  console  has  a  small  set  of  control  buttons  and  lights  to  constantly 
Inform  the  user  of  system  status. 

Figure  11  pictures  the  17-ln.  CRT  version  of  the  console.  This 
console  can  display  52  lines  of  characters  in  a  74-character  line, 
flicker-free  format.  Each  station  can  handle  full  graphics  and  con¬ 
tinuous  gray  scale.  The  TV  monitors  are  provided  with  a  polarity 
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SYSTEM  CONTROLS  TV  SCREEN 


3  Cases  Print 
1  Case  Functions 


Fig.  10— Block  Diagram  of  a  Console 
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Fig.  11— Console  with  Rand  Tablet  and  Keyboard 
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switch,  which  allows  the  user  a  choice  of  black  on  white  or  white  on 
black  formats. 

SYSTEM  PERFORMANCE 

The  major  design  criterion  is  a  sufficiently  responsive  and  shar- 
able  system  that  allows  any  of  several  concurrent  users  to  utilize  an 
interaction  capacity  appropriate  to  his  problem.  The  averaging  power 
of  many  concurrent  use***  allows  appropriate  economic  sharing  of  the 
hardware.  Uniform  line-widths,  uniform  brightness,  and  line  closure 
are  important,  and  are  state-of-the-art. 

The  VGS  was  Installed  at  Rand  in  October  1968.  It  has  been  oper¬ 
ational  virtually  24  hr  a  day,  7  days  a  week  since  installation.  Over¬ 
all  reliability  has  been  remarkably  good.  Downtime  has  been  trivial 
and  maintenance  requirements  minimum. 


-24- 


V.  THE  RAND  SYSTEM  SOFTWARE 


Rand's  system  software  packages  consist  of  the  IBM  1800  System 
Software,  the  iBM  360/65  MVT  Operating  System  (OS),  the  Video  Opera¬ 
ting  System  (VOS),  the  Integrated  Graphic  S/  tern  (IGS) ,  the  NCP,  page 
and  graphic  Interfaces  to  IBM's  CPS,  and  a  set  of  FORTRAN-callable 
routines,  called  VPACK,  for  Interactive  and  graphic  needa  (see  Fig.  12). 

IBM  1800  SOFTWARE 

Users  treat  the  1800  software  as  an  extension  of  the  hardware. 

The  1800's  primary  functions  are  to  set  up,  protect,  and  manage  traffic 
through  the  logical  Information  flow  paths  of  the  console-service  ma¬ 
chine.  Other  functions  relate  to  error  analysis  and  recovery,  rote 
task  and  high  interrupt-rate  processing,  and  buffering  to  relieve 
service-machine  loads. 

An  example  of  the  latter  is  the  single  line-text-edltlng  function. 
One  way  for  a  service-machine  program  to  unlock  a  console  keyboard 
(allowing  character  input)  is  by  a  command  to  the  1800  with  initial 
contents  of  a  text  line  that  is  to  be  displayed.  The  1800  updates  the 
given  text  line  as  modified  by  individual  key  strokes  at  the  keyboard. 
When  a  terminal  key  is  stuck,  the  keyboard  is  physically  locked  and 
the  1800  sends  the  resultant  text  line  back  to  the  service  machine. 

Thus,  the  service  machine  sees  only  one  Interrupt  per  line  rather  than 
one  per  key  stroke.  The  1800  software  system  design  is  optimized  for 
this  type  of  job,  so  it  can  handle  many  such  tasks  with  very  quick  re¬ 
sponse,  allowing  a  multitude  of  simultaneous  interactive  displays. 

1800  SOFTWARE  STATUS 

The  1800  software  has  been  running  since  1968,  supporting  all  the 
devices  described,  as  well  as  regular  maintenance  functions.  Revisions 
have  recently  been  made  to  support  a  connection  to  the  ARPA  Network  and 
some  experimental  terminal  devices. 
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THE  VOS 

This  software  resides  In  a  general  OS  multiprogramming  environment 
operating  under  IBM  OS  MVT  as  a  high-priority  task. 

I ts  major  functions  are 

o  To  act  as  the  general  communication  agent  for  each  program, 

In  a  multiprogramming  environment; 

o  To  create,  manage,  and  pollc-  insole-to-program  and  program- 
to-console  connections  according  to  requests  on  the  part  of 
consoles  and  programs  (the  IMP  Is  treated  as  a  console); 

o  To  receive,  queue,  route,  and  concentrate  messages  to  and 
from  the  1800; 

o  To  manage  and  distribute  control  messagss. 

VOS  acts  as  a  communications  controller  within  a  service  machine 
to  pass  messages  between  programs  In  the  service  machine,  VGS  consoles, 
and  the  Network.  That  Is,  program-to-program,  program-to-console, 
console-to-program,  console- to-console,  Network-to-prograu  (NCP) ,  and 
program-to-Network  (NCP)  communications  are  possible.  The  programs 
may  be  multi-access  subsystems,  which  communicate  concurrently  with 
multiple  consoles  or  with  the  Network. 

Figure  13  shows  the  component  routines  of  VOS.  Their  functions 
are  to  receive,  route,  enqueue,  and  deliver  messages.  The  routines 
operate  Independently;  some  are  executed  as  subtasks  whereas  others 
exist  as  shared  subroutines  callable  by  either  system  or  user  programs. 
Each  subtask  Is  enabled  by  and  responds  to  one  or  more  of  the  following 
ex'ent  types: 

o  Acceptance  of  an  1800  attention. 

o  Completion  of  a  read  operation  by  OS. 

o  Successful  completion  of  the  Input  of  a  message  from  the  1800. 

o  Acceptance  of  a  message  from  a  program. 

o  Appearance  of  a  message  on  the  queue  of  messages  to  be  trans¬ 
mitted  to  the  1800. 

o  Completion  of  a  write  operation  by  OS. 

In  Fig.  13,  the  receiver  reads  messages  transmitted  to  the  service 
machine  from  the  1800.  The  distributor  is  the  central  component  of  VOS. 


It  responds  to  the  occurrence  of  a  "message-to-go"  event  from  either  the 
receiver  or  the  pickup.  The  deliverer,  shared  by  all  destination  pro¬ 
grams,  manages  the  access  to  messages,  which  are  either  waiting  in  its 
program  destination  queue  or  expected  to  arrive  there.  The  pickup, 
shared  by  all  programs  acting  as  message  sources,  notifies  the  distri¬ 
butor  of  the  existence  of  a  message  (originating  from  a  proper  source) 
to  be  distributed.  The  sender  transmits  messages  to  the  1800.  The 
message-path  manager,  shared  by  all  programs,  services  requests  for 
initiation,  completion,  blocking,  or  deletion  of  message  paths. 

IGS 

IGS  is  a  graphic  subroutine  package  callable  from  PL/1  or  FORTRAN 
[26].  It  is  OS  compatible  and  display-device  Independent  (i.e.,  it  can 
support  an  IBM  2250,  VGS  consoles  with  several  input  devices,  and  the 
Stromberg  Carlson  4060  hardcopy  recorder)  .  IGS  allows  existing  pro¬ 
grams  to  be  transferred  unchanged  from  the  IBM  2250  to  the  VGS.  Pre¬ 
sumably,  the  reverse  is  also  true;  however,  this  has  not  been  tested. 

The  IGS  package  currently  supports  all  former  2250  display  calls 
and  input-device  management  and  messages,  including  the  character- 
recognition  package  associated  with  a  Tablet.  A  large  portion  of  IGS 
is  currently  being  revised  to  be  re-entrant  for  more  efficient  multi¬ 
user  use. 

NCP 

We  stated  that  the  NCP  is  normally  a  part  of  the  basic  system 

software.  In  the  interim,  Rand  has  treated  the  NCP  as  a  standard  OS 

user  program  rather  than  Including  it  in  the  host  IBM  1800  operating 

system.  As  a  user  program,  the  NCP  may  be  debugged  and  manipulated 

without  the  Inconveniences  associated  with  verifying  system  code  in 

f 

an  operational  environment. 


Treating  the  NCP  as  a  user  program  was  a  good  choice.  Implemen¬ 
tation  time  has  been  short,  compared  to  other  sites  where  the  NCP  was 
written  as  part  of  the  basic  system  software.  The  short  implementa¬ 
tion  time  can  be  attributed  to  (1)  treating  the  NCP  as  a  user  program, 
(2)  code  checking  with  the  use  of  an  on-line  debugger,  and  (3)  the 
existing  facilities  provided  by  VOS  that  allowed  access  to  the  IMP. 
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The  purpose  of  the  NCP  is  to  (1)  extend  the  VOS  connection  fa¬ 
cility  to  initiate  and  switch  logical  connections  (message  paths) 
between  local  programs  and  remote  Network  programs,  using  the  Network 
dialogue,  and  (2)  switch  messages  between  service-machine  programs 
and  remote  Network  programs  in  the  Network  dialogue. 

The  NCP  consists  of  a  task  dispatcher,  three  asynchronous  routines, 
tasks  to  interpret  and  generate  Network  protocol,  and  miscellaneous 
subroutines  and  data  tables  (Fig.  14). 

The  NCP's  interfaces  are  the  asynchronous  routines,  namely,  the 
VOS  message-path  transition  routine,  the  VOS  message-arrival  routine, 
and  the  interval-timer  routine.  By  placing  messages  in  the  circular 
queues  shown  in  Fig.  14  anti  posting  an  asynchronous  event,  these 
routines  affect  the  scheduling  of  Instances  of  the  Network  tasks,  via 
the  task  dispatcher. 

The  task  dispatcher  is  the  "control  program"  of  the  NCP.  It  is 
initiated  when  an  event  is  posted  by  an  asynchronous  routine  and,  in 
turn,  initiates  a  task  based  upon  messages  placed  in  the  circular 
queues . 

A  description  of  the  NCP  and  its  use  will  be  contained  in  forth¬ 
coming  reports. 

SERVICE-MACHINE  PROGRAMS 

Service-machine  programs  may  communicate  with  local  consoles, 
other  service  machine  programs,  and  remote  Network  programs  by  estab¬ 
lishing  the  appropriate  VOS  and  NCP  message  paths.  Figure  15  shows 
message  paths  for  typical  programs.  Many  paths  between  programs  and 
consoles  may  be  maintained  concurrently. 

Section  VI  describes  our  current  work  in  the  area  of  program  and 
console  communications. 
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Fig.  14— NCP:  Interface  between  the  Dispatcher  and  the 
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Fig.  15--Typical  Message  Paths  Through  VOS 
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VI.  RAND  PROGRAM  AND  TERMINAL  COMMUNICATION 

GOALS  OF  USER  PROGRAMS 

Many  Network  sites  will  soon  undertake  meaningful  experiments  and 
provide  useful  services.  Rand  Is  attempting  to  combine  much  of  these 
two  bbjectlves  Into  a  common  user  program. 

The  typical  Rand  researcher  Is  unfamiliar  with  the  details  of  the 
VGS  or  the  Network  and  usually  has  little  time  to  learn  them.  Thus, 
there  Is  an  Increasing  tendency  to  consult  a  programmer,  who  serves  as 
a  buffer  between  the  VGS/Network  and  the  researcher.  Our  objective  is 
to  eliminate  the  need  for  this  buffer — to  integrate  the  resaarcher 
smoothly  into  an  on-line,  remote  environment. 

A  second  site  objective  Is  to  provide  an  environment  that  allows 
an  Investigator  to  address  the  problems  of  disparate  software  Inter¬ 
communications.  It  Is  desirable  to  adapt  to  Network  use  problem  pro¬ 
grams  that  were  not  planned  with  the  Network  In  mind  and  that  will  not 
readily  yield  to  Network  standards  existing  at  the  time  of  their  in¬ 
clusion.  We  do  not  wish  to  add  an  Interface  to  each  such  program  so 
that  It  meets  Network  standards.  A  similar  problem  confronts  those 
sites  with  a  minimal  host  computer  that  wish  to  offer  a  variety  of 
dissimilar  Network  services  to  their  terminal  users. 

There  are  two  problems — that  of  protocols  above  the  NCP  level  for 
parties  or  processes  to  contact  one  another,  and  that  of  data  formats 
amenable  to  the  parties  at  both  ends  of  an  established  connection.  One 
approach  to  the  protocol  and  data-format  problems  is  to  provide  an 
adaptable  mechanism  (at  strategically  located  hosts  throughout  the  Net¬ 
work)  that  can  generate,  on  demand,  custom-protocol  sequences  for 
message-path  management  and  that  can  reconfigure  data  passing  between 
connected  parties. 

THE  NETWORK  SERVICES  PROGRAM  (NSP) 

Rand  has  combined  remote-service  support  and  experimentation  into 
a  common  program,  the  NSP,  which  allows  Rand  researchers  to  access  re¬ 
mote  resources  from  VGS.  In  particular,  provisions  are  included  to 
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sacisfy  the  previously  described  needs  of  the  Rand  researchers.  NSP 
also  Includes  test  modules  by  which  we  will  investigate  general  proto¬ 
col  and  data-format  handling. 

The  NSP  is  a  multi-access  program,  driven  either  from  console 
or  programs,  that  operates  as  an  OS  user  program  (Fig.  15).  The  NSP 
nucleus  is  identical  to  the  one  described  for  NCP  (Fig.  14),  with  two 
additional  asynchronous  routines  and  queues  for  internally  generated 
messages  among  NSP  modules  and  for  Interrupts  resulting  from  secondary 
storage  transmissions. 

Figure  16  shows  the  tasks  (or  modules)  currently  being  implemented 
for  NSP.  Their  functions  are  described  below: 

o  The  Console/Program  Manager  interfaces  NSP  to  the  VGS  consoles 
and  other  service-machine  user  programs,  via  VOS;  it  handles 
the  requisite  console  dialogue. 

o  The  NCP  Manager  handles  Network  communication  protocol  through 
the  NCP  to  establish  and  maintain  connections  to  remote  programs. 

o  The  File  Manager  provides  the  NSP  access  to  disk  data  sets. 

It  can  dynamically  open,  close,  read,  write,  and  create  data 
sets  as  directed  by  NSP  console  users  or  Network  programs. 

o  The  UCSB  Manager  permits  on-line  use  of  RJE/RJS  at  UCSB. 

o  The  RJS  Manager  will  satisfy  a  particular  research  group's 
need  by  conducting  a  specially  needed  protocol  dialogue. 

A  comprehensive  description  of  NSP  and  its  use  will  be  contained 
in  forthcoming  reports. 
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Fig.  16— Network  Services  Program 
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